REMARKS 



This application has been reviewed in light of the Office Action dated March 1, 2005. 
Claims 1-15 and 17-29 are pending in the application. Claim 16 is cancelled without prejudice. 
Claims 1-15 and 17-19 are amended in a manner that Applicant believes overcome the rejections 
in the Office Action. New claims 20-29 are added. Support for the amendments can be found 
throughout the specification and figures of the present disclosure and recite aspects of the 
disclosure that Applicants are believed to be entitled. Applicants submit that no new matter or 
issues are introduced by the amendments. Applicants reserve the right to prosecute the subject 
matter of any cancelled claims in continuing applications. Applicants respectfully submit that in 
view of the amendments and remarks herein, all claims presently pending in the application are 
allowable over the art of record. 

Priority Claim 

Applicant submits that the specification has been amended to include the provisional 
application number, to comply with conditions for receiving the benefit of an earlier filing date 
under 35 U.S.C. 119(e). 

Objections to the Specification and Claim 19 

Claim 19 has been amended to start with a capital letter as requested by the Examiner. 
The Office Action alleged that certain informalities were contained in the Specification. 
Applicant respectfully submits that typographical errors in the Specification have been corrected 
herein. Reconsideration and withdrawal of the rejection is respectfully requested. 

101 Rejection 

In the Office Action, Claims 1-14, 19 were rejected under 35 U.S.C. 101 as being 
allegedly directed to non- statutory subject matter. The Examiner states (on page 3): 
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"claims 1-14, 19... do not involve, use or advance the technological arts. The 
recited database in the claims may be a file storage that does not have to be in a 
computer, e.g., a file cabinet". 

As suggested by the Examiner in a telephone conversation held August 4, 2005, claims 1- 
14 and 19 have been amended to recite a number of "computer databases". Accordingly, it is 
respectfully submitted that the invention as claimed in amended claims 1-14 and 19 is clearly 
within the technological arts, i.e. computer systems. 

The Examiner further alleges that "claims 9-11 recite the inputting steps only, and there 
is no output. . .[and] therefore, fail to produce a useful, concrete and tangible result. . ." Applicant 
submits that independent claim 9 has been amended to overcome the rejection. Applicant 
therefore requests that the rejection of claim 9 and claims 10-11 depending therefrom be 
withdrawn. 

Additionally, the Examiner acknowledges that "the recited process in claims 1-8, 12-14, 
19 produces a useful, concrete, and tangible result" (middle of page 4 of the Office Action). In 
view of the foregoing, it is respectfully submitted that the invention as claimed in claims 1-14 
and 19 is statutory under 35 U.S.C. 101, and thus reconsideration and withdrawal of the 
rejections are requested. 

112 Rejections 

Claims 1-7, 9-14 and 19 were rejected under 35 U.S.C. 112, second paragraph, as being 
indefinite. Applicant respectfully submits that Claims 1-7, 9-14 and 19 have been amended so to 
overcome the rejection. 

In particular, the Examiner alleges that: 

"per claims 1,7, the claims recite a system, however, there is no structural 
limitation(s) in the body of the claims to support the recitation of the system (i.e., 
"the computer implemented system 1 ', and "the medical data utilization system") 
recited in the preamble." 



12 



Applicant submit that independent claims 1 and 7 have been amended so to overcome the above- 
quoted rejection. In this regard, Fig. 1 and paragraphs 33-38 of the present Application clearly 
disclose each and every structural limitation of Applicant's system as claimed, including a user 
interface module 20, a navigation module 21, a verification module 22, and a number of 
computer databases 24, 26, 26. Accordingly, in view of the amendments to claims 1-7, 9-14 and 
19 and for the foregoing reasons, reconsideration and withdrawal of the rejections are 
respectfully requested. 

In the Office Action, claims 8-11 and 15-17 were rejected under 35 U.S.C. 102(b) as 
being allegedly anticipated by Provost et al (6341265). However, it is respectfully submitted that 
amended independent claim 8, amended independent claim 9 and claims 10-11 depending 
therefrom, amended independent claim 15 and claims 16-17 depending therefrom are clearly not 
anticipated by Provost. 

The Office Action at paragraph 9 alleges "Provost discloses a method for submitting 
clinical record (i.e. claim payment) for automated processing. 5 ' However, Applicant respectfully 
submits that a claim payment is not a clinical record, but is rather a request for payment for 
services provided. Similarly, a claim form consists of one or more diagnosis codes (ICD9 codes) 
and one or more procedure codes (CPT4 codes) for patient care and contains no fields for actual 
clinical findings. A claim form has no clinical format. 

A clinical record documents a patient's clinical status and care by a clinician. A clinical 
record includes the documentation of a patient's symptoms, examination, the ordering and 
results of lab tests, the ordering and results of lab tests diagnostic, treatments and medications. 
The data entry displays clinical findings in a clinical chart format used by clinicians in the 
practice of medicine. 

The Office Action further alleges Provost discloses "providing a selection interface, 
adapted to facilitate the user selection of one of a plurality of values." However, the user 
interface of Provost allows only manual entry of data values rather than selection from a list of 
values. Moreover, the phrase selection interface does not reflect the functioning of the interface. 
There is no selection from a list of values, within the user screen. Selection is done by a user by 
reviewing an entirely separate volume entitled Physician's Current Procedural Terminology and 
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is not integral to the health claim system. Applicant's invention displays a selection interface 
with multiple pop-up lists for user interaction. 

The Office Action further alleges that Provost discloses "receiving a selection (i.e. 
diagnosis code, dollar amount) from the selection interface." However, no selection is being 
made (i.e., diagnosis code, dollar amount are being manually entered). Data entry is being 
performed, (col. 11 lines 29-33). The phrase "selection interface" does not reflect the 
functioning of the interface. There is no selection from a list of values. The present invention 
receives a selection from pop-up lists (i.e., selection from diagnosis pop-up lists, selection from 
criteria pop-up lists, and selection from Element, System/Group, Parameter, Finding pop-up 
lists). 

The Office Action further alleges that Provost discloses "providing data fields in response 
to the selection, data fields includes quantified data field (i.e. dollar amount) associated with 
objective criteria (i.e. treatment code), the data fields are evaluated for automated processing of 
the clinical record." However, there is no selection of a value from a list so that there is no entry 
into a data field by a selection process and therefore no response. Entry into a data field is done 
by manual typing into the field, rather than by a selection process. Moreover, automated 
processing is done on a server system (col. 9 lines 65 to col. 10 line 6) and not done on the client 
system. Therefore status of submitted claims is not instantaneous, "but a relatively short amount 
of time" (col. 11 lines 49-52). 

In contrast to Provost, Applicant's invention processes authorization of care on the client 
system in real-time as data is being entered, and does not require submission to the server system 
with an authorization response then returned to the client system. Authorization processing is 
instantaneous. In Provost, the automated processing is done for codes, not for a clinical record. 
Applicant's source automated process evaluates clinical findings of the patient encounter. 
Furthermore, a claim payment is not a clinical record. 

The Office Action alleges that "Provost discloses a method for entering medical 
diagnosis data comprising: a. entering a diagnosis into the system." However, the present 
invention allows entering one or more diagnoses by selection from a pop-up list populated by 
selecting an ICD9- group consisting of a range of ICD9 codes, e.g.,. ICD9 code 486 is selected 
from a list of codes populated by selecting the ICD9 Coded Group 460-519. 
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The Office Action alleges that Provost discloses "entering a criteria into the system 
corresponding to a rule required for authorizing a diagnosis, the criteria associated with at least a 
finding." However, authorization is not for diagnosis, but for treatment services (CPT4 codes) 
enumerated. The diagnosis code is the criterion. Treatment codes may be for multiple 
encounters on multiple dates. (Fig 3). Applicant's claimed criteria are clinical findings required 
for a given diagnosis for a single patient encounter. 

The Office Action alleges that Provost discloses "entering a finding (i.e. nature of 
illness)." However, a diagnosis code identifies the patient's illness but does not record the 
specific clinical findings made by the health care provider. There are no clinical findings to 
support the diagnosis code. Applicant's invention records specific patient findings made by the 
health care provider, e.g., which are required to support the diagnosis code, e.g., Wheezing heard 
on auscultation of (listening to) the chest is displayed, e.g., Chest: Auscultation: wheezing. 

The Office Action alleges that Provost discloses "addition data corresponding to the 
finding (i.e. nature of illness) such as patient information, treatment code and charges can be 
entered." However, Applicant's concatenates allows multiple additional findings for a clinical 
parameter on a single line. Findings are concatenated for a single parameter, e.g., the finding of 
ronchi (coarse sounds) is added to the finding of wheezing for chest auscultation, e.g., Chest: 
Ausculatation: wheezing; ronchi. 

The Office Action alleges "Provost teaches that the user can request for resources 
provided by server, as well as additional selection interface to resubmit denied procedures." 
Applicant submits, however, that a claim denial transmitted to the client system does not 
constitute a specific request for specific information and represents only a notice of a denial 
action on the claim. A resubmission of the claim with a new treatment code represents an 
alternate attempt at having the claim authorized. 

Applicant's invention allows a medical reviewer request for specific additional 
information relevant to a diagnosis and encounter to support the diagnosis and counter. This 
query is returned to the client system in the format of one or more prompts (like the diagnosis- 
based prompts) which populate and make selections in the Element, System/Group and 
Parameter lists. The Finding pop-up list is populated to enable a response to the query by the 
user. 
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The Office Action alleges Provost teaches "establishing an internet site that provides 
forms that facilitate the entry of procedural data." Applicant's invention, in contrast, also allows 
user interaction on a local area network, single computer. The Office Action further alleges 
Provost teaches "configuring the forms to apply a first set of rules," However, Applicant's 
claimed rules are for each criterion as well as for the entire patient encounter and are first 
executed on the client system. It is further asserted in the Office Action that Provost teaches 
"receiving medical procedure data from medical care provider." and "processing and receiving 
data are used as criteria." However, Applicant's medical procedure data refers to clinical data, 
and both the first set and second set of rules are operative real-time on the client site. 

The Examiner asserts that "both first and second sets of rules are used as criteria." 
However, Provost's first set is used only to evaluate eligibility of claim. The second set is used 
to decide approval of procedures. Applicant's first set of rules apply to individual diagnosis- 
derived criteria, and the second set of rules apply to the patient care encounter as a function of 
meeting criteria of one or more diagnoses for the patient clinical encounter. 

The Examiner contends Provost discloses that "if authorization of care fails, the system 
informs the health care provider." However, the system informs the health care provider only 
after the data has been received from the client system for processing by the server. The server 
then sends out the notification of a failed authorization to the client system, (col. 10 lines 53-56). 
The health care provider gets no notification of an authorized claim. Applicant's invention 
informs a user of authorization status real-time and instantaneously, while the user is entering 
data on the user system and prior to submission of data to the server system. The server system 
does not need to inform the user of authorization status. 

Because of the above distinctions, it is respectfully submitted that amended independent 
claim 8, amended independent claim 9 and claims 10-11 depending therefrom, and amended 
independent claim 15 and claims 16-17 depending therefrom are clearly not anticipated by 
Provost. Reconsideration and withdrawal of the rejections are respectfully requested. 

In paragraph 11 of the Office Action, claim 7 was rejected under 35 U.S.C. 103(a) over 
U.S. Patent No. 6,341,265 to Provost et al. Specifically, the Examiner contends Provost 
disclosesllA) a "user interface to submit data to the system." However, the user screen is a 
simple health insurance form requiring manual entry into multiple fields In contrast, Applicant's 
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user screen care is a clinically formatted screen which prompts for data entry by criteria pop-up 
list and allows data entry by selection from the Finding pop-up list. While the Office Action 
alleges Provost shows "a selection database," Applicant submits that no data selections are 
available to user. A user manually enters data into an on-screen an insurance form. What the 
Examiner misconstrues as a verification module resides on the server computer and is coupled by 
the internet. In contrast, Applicant's verification module is downloaded with the forms to the 
user system and is coupled with the form on the user system. 

The Office Action acknowledges that "Provost fails to explicit recite the navigation 
module. However, it is readily apparent that navigation keys and bar are needed for controlling 
cursor movement." Whereas Provost mentions simple forms for completion by user guide cursor 
movement by simple use of tab key to arrive at the next field to be entered, Applicant's 
navigation module allows the populating of multiple pop-up lists, in response to the selection of 
an item in a criteria-based prompt list to offer the user a selection of findings. This selection is 
entered on a clinically formatted screen. Applicant's navigation module allows all data entry to 
be done by user interaction of two fields, e.g., the criteria prompt list selection and the finding 
list selection populated by the prompt list selection. Alternatively, numerical value entry for a 
finding is selected by the criteria prompt list selection. The capability of organizing the screen 
interface as a clinical chart and to be able to modify the complex organization and data input of a 
clinical chart to enable a selection response to a criteria prompt take more than ordinary skill in 
the art. 

The Examiner alleges Provost teaches "a data entry interface for entering data 
corresponding to medical diagnosis." However, the data entry for treatment (CPT4 or 
procedure) code can be any treatment code provided by the health care provider and does not 
necessarily have to correspond do medical diagnosis. For example, if the diagnosis code is for 
fractured wrist, the treatment code might be electrocardiogram. There is not necessarily a 
corresponding relationship. In contrast, Applicant's invention guides for clinical data 
corresponding to diagnosis. Prompts for data are derived from the diagnosis. A selection of a 
prompt populates multiple pop-up lists to allow selection of a clinically relevant finding. 

Although the Office Action asserts Provost discloses "selection interface for selecting at 
least one diagnosis," Applicant submits that the diagnosis is not selected, but is entered. In 
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contrast, Applicant's diagnosis is selected or entered. While the Examiner alleges Provost shows 
"a verification module for determining authorization status and diagnosis authorization," 
Applicant submits that the verifying element resides on the server computer. Diagnosis is not 
authorized. Rather appropriateness of treatment codes for states diagnosis is authorized. In 
contrast, Applicant's verification module is downloaded with the form to the user system to 
concurrently review data entry and confer authorization prior to return of the data to the server 
system. The server system does have a second verification module to confirm authorization. 
This second verification module does not modify the authorization conferred on the user system 
during data entry. 

In view of the foregoing, Applicant respectfully submits that amended claim 7 is 
therefore patentable over Provost, and request that the rejection be withdrawn. 

In paragraph 12 of the Office Action, claims 1-6 were rejected under 35 U.S.C. 103(a) 
over Provost et al. (6341265) in view of Jacobs et al. (6049749). Specifically, the Examiner 
alleges Provost discloses "a patient medical record management system." However, Provost 
describes a claim editing and management system. A claim is not a clinical record. Although 
the Examiner further asserts Provost shows a "data interface system for entering data 
corresponding to medical diagnosis," Applicant submits that data for treatment code is not a 
function of the medical diagnosis, but a statement of services provided. Although the Examiner 
asserts Provost discloses "selection interface for selecting at least a diagnosis," Applicant notes 
that such diagnoses are manually entered and not from a selection interface. 

While the Office Action alleges Provost discloses "a verification module for determining 
status authorization and diagnosis authorization," Applicant submits that Provost's diagnoses are 
not authorized, payment for treatment services are authorized, and any alleged verifying element 
resides on a server computer. In contrast, Applicant's invention authorizes a patient clinical care 
encounter by criteria derived from a diagnosis code. The verification module is downloaded to 
the user site with clinical form display and is done real-time on the user site as user enters data. 
While the Examiner contends that "Provost discloses authorization for determining 
appropriateness of level of diagnosis, Applicant submits that such authorization is not for 
diagnosis, but for the treatment codes submitted with the diagnosis. There is no data that is 
required to support entry of diagnosis. 
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The Examiner alleges "it is well known as evidenced by Jacobs et al.... to include level of 
care/diagnosis... for improving treatment plan." However, Jacobs determines verification on a 
single "indication", which is usually a single clinical finding and not on a diagnosis, which is 
usually derived from multiple findings. User checks off checkboxes associated with "criteria 
points" statements. Feedback is given only as authorization status, as a function of which 
checkboxes have been checked off. In contrast, Applicant's system determines verification by 
diagnosis, whereby the user enters multiple clinical findings onto a clinically formatted display. 
Clinical data is prompted for, by diagnosis-derived criteria and enables a clinical methodology 
for reviewing patient care. Feedback is given for each criterion as well as for the diagnosis. The 
system reviews care concurrently and retroactively, as well as intended care. It takes more than 
ordinary skill to provide verification and feedback based on the actual clinical status of a patient. 
This requires a user interface which gathers the clinical data in a uniform way, presents the data 
in clinical chart format and evaluates this data by complex diagnosis criteria. 

While the Examiner alleges Provost discloses "codes corresponding to selected 
diagnosis," Applicant submits that Provost does not authorize diagnosis, but only treatment 
codes. Authorizing eligibility of user, verifying accuracy and completeness of inputted data are 
generic functions, e.g., credit card information when shopping on-line. In contrast, Applicant's 
system reviews actual clinical data relevant to the patient's clinical status, rather than treatment 
codes which require no clinical data. 

Although the Examiner asserts Jacobs determines a level of care and provides feedback, 
Applicant submits that Jacobs determines verification on a single "indication", which is usually 
a clinical finding and not on a diagnosis. A user checks off checkboxes associated with "criteria 
points" statements. Feedback is given only as authorization status, as a function of which 
checkboxes have been checked off. In contrast, Applicant's system evaluates the 
appropriateness of a patient clinical encounter by one or more criteria-dependant diagnoses and 
gives feedback for each criterion, each diagnosis and for the overall patient clinical encounter. 
Feedback is also given as on-screen presentation of the entered data in a clinically formatted 
chart note display. For example, for the diagnosis code of asthma, wheezing is required on chest 
auscultation (listening). A finding that states that ausculation is "within normal limits" would 
provide feedback that this finding is inconsistent with diagnosis. For example, for the diagnosis 
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code of pneumonia, a treatment finding of adrenalin (rather than an antibiotic) would provide 
feedback that this treatment does not meet expected treatment. 

While the Examiner alleges Provost teaches "patient claim forms," Applicant submits 
that Provost combines patient information which serves as a header to the code information, 
which requires scrolling. In contrast, Applicant claims a "single screen display," meaning that 
the screen displayed after loading a clinical screen does not require scrolling for patient data 
entry. 

In view of the foregoing, Applicant respectfully submits that amended claim 1 and claims 
2-6 dependent therefrom are patentable over the combination of Provost and Jacobs. 
Reconsideration and withdrawal of the rejection be respectfully requested. 

In paragraph 14 of the Office Action, claim 19 was rejected under 35 U.S.C. 102(e) as 
being allegedly anticipated by Jacobs et al. (6049794). Specifically, the Examiner alleges Jacobs 
discloses "providing a selection interface to select a diagnosis criteria... receiving diagnosis 
related data... applying verification rules to the received data... [and] providing an indication of 
verification." However, Jacob's alleged selection interface consists of multiple screens and 
"criteria points" with check boxes. No diagnosis criteria is offered, and criteria are "criteria 
points" derived from an "indication". Data entry consists of checking boxes associated with 
"criteria points", and the data is not diagnosis-related but related to a single indication. 
Verification is done for the selected indication after appropriate "criteria points" have been 
checked off, and verification is indicated only for the indication. 

In contrast, Applicant's selection interface consists of a single screen display requiring no 
scrolling and selection of two pop-lists: a criteria diagnosis-dependant pop-up list and a findings 
pop-up list. Verification is done for the clinical encounter when appropriate diagnosis-base 
clinical findings has been entered. Applicant's verification is also done for each clinical finding 
as it is entered, as well as for the diagnosis and patient clinical encounter. Finally, verification is 
indicated for each clinical finding as well as diagnosis patient encounter. In view of the 
foregoing, Applicant submits that amended claim 19 is patentable over Jacobs. 

In paragraph 15 of the Office Action, claims 12-14 and 18 were rejected under 35 U.S.C. 
103(a) over Jacobs et al (6049794) in view of Provost et al. (6341265). Specifically, the 
Examiner states Jacobs teaches "a portion of the display to facilitate selection of a system group 
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(i.e. criteria set)." However, a criteria set is an upstream, overarching grouping which begins the 
user selection process and comprises categories of services. Selection of a criteria set then 
requires selection of a clinical system/body system which then requires selection of a procedure 
which then requires selection of an indication which then displays criteria points. 

In contrast to Jacobs, Applicant's invention facilities entry of clinical data by populating 
multiple pop-up lists appropriate to the user selected prompt. The "System/Group" pop-list 
refers to a subset of the chart "Element" such as, Exam, Lab, Rx. A System/Group refers to a 
pop-up list populated by selecting an item in the Element pop-up list, e.g., selecting Exam in the 
Element pop-up list populates the system group with HEENT, Neck, Chest, Abdomen, etc. 
Selecting Lab in the Element pop-up list populates the System/Group with Chemistry, 
Hematology, Microbiology, etc. Selecting Rx (treatment) in the Element pop-up list populates 
the system group Indwelling objects, Meds IV, Meds Oral, Orders, Ventilator, etc. 

The Office Action asserts Jacobs discloses "a portion of display selection .... where in 
display data changes." However, the displayed data changes in response to selection by 
displaying new user screens or by displaying a checked off box. In contrast, Applicant's 
displayed data changes refers to the repopulated pop-up button lists within the same screen 
display and the display of entered data in a clinically chart format on screen. 

The Examiner alleges Jacobs teaches "display area for displaying parameters and 
findings (i.e.. indications and criteria points)." However, an indication is an upstream selection 
point in the user selection process that sets up criteria points to be displayed. In contrast, 
Applicant's parameter is a clinical action, which requires a description with one or more clinical 
findings, e.g., The Parameters for the System/Group Chest are Observation, Palpation, 
Percussion, Auscultation. Applicant's parameter is a clinical category, which requires a 
selection of one or more clinical findings, e.g., The Parameters for the System/Group Meds IV 
(medications intravenous) include Vasopressors, Antibiotics, Steroids, etc. Whereas Jacob's 
criteria points are groups of clinical statements, each statement preceded by an empty check box, 
Applicant's findings are, in contrast, clinical terms used as clinical findings to describe the 
parameter of the patient's clinical status and appear within the Findings pop-up list. For 
example, the findings pop-up list for the Parameter Ausculation for the System/Group Chest 
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include rales, ronchi, rub, and wheezing. For another example, the Findings pop-up list for the 
Parameter Meds IV include ampicillin, cephalosporin, flagyl, etc. 

The Examiner asserts the reference teaches "data entry means for selecting of findings 
and parameters." However, selection of a criteria point consists of checking of the checkbox 
next to the criteria point statement. In contrast, Applicant's selection of a finding results in the 
display of the finding in a clinically formatted screen. Multiple findings for the same Parameter 
are displayed on one line. Findings for multiple parameters for one Element (e.g. Exam, Rx) are 
displayed each on a separate line. For example: 

Exam 

Chest Auscultation: wheezing, ronchi 
Chest Palpation: tenderness 

Abdomen: Palpation: absent bowel sounds; guarding 

Diagnostics 

X-rays Chest: acute pleural effusion 

CAT Scan: Abdomen: air fluid level; ascites 

Rx 

Meds IV- Antibiotics: ampicllin 
Orders-Diet: full liquids 

The Examiner acknowledges that "Jacobs teaches multiple screens and fails to expressly 
recite a single screen," but asserts this feature is obvious in view of Provost. However, a central 
feature of Applicant's invention is to offer a single screen requiring no scrolling for clinical data 
entry in clinical format to make the user interaction gain user acceptance. It takes more than 
ordinary skill to provide a single non-scrollable interface which enables the gathering of relevant 
clinical information specific to one or more diagnoses of a patient encounter and presents the 
clinical information in clinical chart format. It takes more than ordinary skill to create a two step 
process to enable the gathering of clinical data for any patient encounter. Step one is the 
selection of a prompt. Step two is the selection of a finding. 

In view of the foregoing, Applicant submits that claims 12-14 and 18 are patentable over 
Jacobs and Provost taken either alone or in combination. 
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CONCLUSION 



In view of the foregoing amendments and remarks, it is respectfully submitted that claims 1- 
15 and 17-29 presently pending in the application are believed to be in condition for allowance and 
patentably distinguish over the art of record. An early notice thereof is earnestly solicited. 

If the Examiner should have any questions concerning this communication or feels that an 
interview would be helpful, the Examiner is requested to call the Applicants 1 undersigned attorney. 

Please charge any deficiency as well as any other fee(s) which may become due at any 
time during the pendency of this application, or credit any overpayment of such fee(s) to Deposit 
Account No. 50-0369 . Also, in the event any extensions of time for responding are required for 
the pending application(s), please treat this paper as a petition to extend the time as required and 
charge Deposit Account No. 50-0369 therefore. 



Respectfully submitted, 




Date: August 3 1 , 2005 



Damon A. Treitler (Reg. No.: 48,377) 
Attorney for Applicant(s) 
Customer No. 21710 

BROWN RUDNICK BERLACK ISRAELS LLP 
One Financial Center 
Boston, MA 021 11 
Tel: (617)856-8412 
Fax: (617)856-8201 
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